개요

이번 주차부터 본격적으로 내부 트래픽 관리 방법을 파헤친다.
이스티오 설정의 핵심 원리와 작동 구조는 결국 엔보이에 기반한다는 것을 항상 숙지하고 있으면, 이스티오는 그다지 어렵지 않..으면 좋겠는데 어렵다
아무튼 트래픽 관리에 사용되는 기본 리소스들을 차근 차근 익혀가면 조금 더 이해도를 높여보자.

사전 지식

책에서 나온 개념은 간단하게만 짚겠다.
이번에 핵심적으로 다룰 트래픽 관리의 필요성을 나타내는 기반이 되기 때문이다.

배포와 릴리스

개발한 것들은 운영 환경에 실제로 배치하는 것을 배포(deployment)라고 한다.
흔히 생각하는 것은 운영 환경에 배치하는 것이 곧 유저의 트래픽을 받는 것으로 이어지는 것이나, 책에서는 여기에서 한 단계를 더 분리한다.
배치를 하고 실제로 트래픽을 받지 않는 채로 여러 테스트를 진행하거나 설정을 하는 것이 가능하며, 충분한 모니터링 이후에 실제 트래픽을 받도록 할 수도 있다.
이렇게 배포 이후에, 실제로 유저의 트래픽을 받도록 하는 과정을 릴리즈(release, 릴리스가 더 발음에 맞는 표현)라고 한다.
새로운 코드를 운영 환경에 도입하는 위험성을 줄이려면 배포와 릴리스를 분리하는 것이 중요하다.
이스티오는 이때 릴리스를 위해, 테스트를 위해 다양한 트래픽 관련 설정을 할 수 있다!

Virtual Service란?

이스티오의 대표적인 리소스로, 트래픽 라우팅 설정을 하는데 사용된다.
이름이 가상 서비스이지만, 실질적으론 쿠버네티스의 인그레스를 대체하는 리소스 정도로 이해하는 게 좋다.

기본이 되는 리소스인 만큼, 기능이 정말 많은데, 간단하게는 이렇게 요약할 수 있겠다.

• 라우팅
  • 트래픽을 보낼 목적지 설정
  • 헤더, url 등의 정보를 토대로 트래픽을 매칭하여 라우팅
  • 라우팅하지 않고 자체적으로 응답
• 트래픽 설정
  • 헤더 추가, uri rewrite 등 요청 자체에 대한 조작
  • 라우팅 가중치, 타임아웃, 재시도, 에러 주입 설정
  • 트래픽 미러링

리소스 등록 시 동작 과정

이 리소스를 만들었을 때 이뤄지는 이스티오의 동작 흐름은 다음과 같다.

• gateways 필드를 토대로 설정을 적용할 엔보이를 정한다.
• hosts 필드를 토대로 엔보이의 라우팅 필터에서 어떤 호스트에 대해 설정을 진행할지 정한다.
• http, tls, tcp 등의 필드의 설정을 그대로 적용한다.
  • route.destination 필드의 업스트림으로 트래픽을 보내도록 설정한다.

버츄얼 서비스는 트래픽 라우팅 관련 설정을 정의하기에, 엔보이에 대해서 RDS 쪽을 건드리게 된다.
이때 데이터 플레인의 모든 엔보이를 설정해버리는 건 아니고 먼저 대상이 될 엔보이를 한정짓는 작업이 들어간다.

목적지 업스트림에는 클러스터(엔보이에서의 클러스터)를 지정해야 하는데, 기본적으로는 쿠버네티스 서비스를 지정할 수 있다.
서비스 메시 환경에서 해당 서비스에 대한 클러스터가 레지스트리로 전부 등록이 돼있어 서비스를 지정하더라도 그냥 클러스터를 지정하는 것과 다를 게 없다.
여기에 이스티오 데스티네이션룰을 설정하여 대상이 되는 클러스터를 부분집합(subset)으로 조금 더 세분화하는 게 가능하다.
데스티네이션 룰에 대해서는 이후 글에서 다루겠다.

버츄얼 리소스 양식 작성법

apiVersion: networking.istio.io/v1
kind: VirtualService
metadata:
  name: reviews
spec:
  hosts:
  - reviews
  gateways:
  - mesh
  http:
  - match:
    - headers:
        end-user:
          exact: jason
    route:
    - destination:
        host: reviews
        subset: v2
  - route:
    - destination:
        host: reviews
        subset: v3

간단하게는 이런 식으로 세팅할 수 있다.
이 설정을 설명하자면,

• 메시 내부의 엔보이를 전부 대상으로 이 설정을 적용하겠다.
• reviews 라는 호스트에 대해 라우팅 설정을 할 것이다.
• 라우팅
  • 헤더에 end-user: jason라는 필드가 들어간다면 reviews v2로 라우팅한다.
  • 아니면 review v3로 라우팅한다.

핵심이 되는 필드만 간략하게 짚겠다.
자세한 정리는 버츄얼 서비스에 공식 문서를 거의 그대로 갖다박았다.

hosts

버츄얼서비스가 적용될 대상 호스트를 지정하는 필드로, 엔보이에서 RDS의 가상 호스트 부분을 설정하게 된다.
웬만해서 FQDN으로 설정하는 게 좋은데, 네임스페이스 별 규칙에 따라 FQDN이 완성되어 이를 기반으로 대상이 될 가상 호스트를 결정하기 때문이다.
그냥 reviews 이런 식으로 세팅하면 다른 네임스페이스에 있는 reviews 서비스로 접근을 못 한다던가 하는 오동작을 할 가능성이 있다.

gateways

  gateways:
  - mesh
  - ingress-gateway

버츄얼서비스의 설정이 적용될 엔보이를 결정짓는 필드이다.
단순하게 보자면 이 버츄얼서비스의 대상이 될 업스트림으로 트래픽을 보낼 다운스트림이 무엇인지 지정하는 필드이다.
이렇게 해석하면 버츄얼서비스로 들어오는 진입점(게이트웨이)을 지정한다는 의미로서 조금 더 직관적으로 이해할 수 있다.
그렇지만 실제 동작 방식을 따지자면 어디까지나 이 필드는 설정을 적용하고자 하는 엔보이가 무엇인지를 나타내는 것임을 유의하자.

여기에 이스티오 게이트웨이를 넣어주면 해당 게이트웨이에 해당하는 엔보이의 RDS에 설정이 적용된다.
mesh라는 값을 넣을 수도 있는데, 이건 현재 서비스 메시 내의 모든 엔보이 사이드카를 대상으로 하겠다는 뜻이다.
게이트웨이를 넣을 때 {게이트웨이 네임스페이스}/{게이트웨이 이름}과 같은 식으로 어떤 네임스페이스의 게이트웨이인지 명시할 수 있다.

http

버츄얼서비스의 핵심 설정들을 넣게 되는 필드로, http 필드 말고도 프로토콜 별로 작성할 수 있다.

• http - HTTP, gRPC, 터미네이션된 TLS 트래픽을 받아 처리한다.
• tls - TLS, HTTPS 트래픽을 처리한다.
  • tls의 ClientHello 단계의 SNI 필드를 보고 라우팅할 수 있다.
  • 실상 조금 특화된 tcp 트래픽 처리 설정이라 보면 되겠다.
• tcp - 그냥 순수한 tcp 처리!

이중에서 설정을 많이 할 수 있는 http 필드를 집중적으로 정리하겠다.

  http:
    # 이름은 디버깅이나 관리용이고, 실제 영향은 없다.
  - name: product
    # 조건 매칭
    match:
    - uri:
        prefix: "/productpage"
	# uri 재작성
	rewrite:
      uri: "/newcatalog"
    # 라우팅 설정
    route:
    - destination:
        host: reviews # reviews.default.svc.cluster.local로 해석된다.
        subset: v2
  - match:
    - uri:
        prefix: "/reviews"
    # 다른 버츄얼서비스로 트래픽 위임
    delegate:
        name: reviews
        namespace: nsB
  - route:
    - destination:
        host: events
        subset: v3

여기에 정말 다양한 설정을 넣을 수 있는데, 일단 전체 구조는 리스트로 작성한다.
이 리스트의 원소들은 순서대로 적용되기 때문에 세부적인 조건이나 설정이 담긴 라우팅 설정일수록 위에 배치하는 것이 좋다.

route

  - route:
    - destination:
        host: reviews.prod.svc.cluster.local
        subset: v2
      weight: 25
    - destination:
        host: reviews.prod.svc.cluster.local
        subset: v1
      weight: 75

라우팅할 업스트림 클러스터를 지정하는 핵심 필드는 route로, 여기에도 대상 목적지를 리스트로 작성한다.
destination.host에 대상 클러스터(서비스, 서비스 엔트리, 데룰)를 명시해주면 된다.
destination.subset이란 필드가 보이는데, 이것은 Istio DestinationRule을 지정해야만 사용할 수 있는 방식으로 해당 클러스터를 부분집합으로 나누었을 때 어떤 부분집합으로 보낼지에 대한 설정을 한다.
이번 실습에서 간단하게 데스티네이션 룰을 사용해 볼 건데 이런 게 있는 갑다 정도만 알아두자.
weight 필드로 가중치를 설정할 수 있다.

matches

  - match:
    - name: jason
      headers:
        end-user:
          exact: jason
      uri:
        prefix: "/ratings/v2/"
      ignoreUriCase: true

어떤 트래픽을 매칭할지 지정하는 필드로, 매칭할 땐 exact, prefix, regex 등을 사용할 수 있다.
이를 기반으로 다음의 필드들을 보자.

• 헤더 관련
  • headers - 헤더를 매칭하는데, 위 예시처럼 대상 삼을 헤더를 필드로 적고 나서 조건 매칭을 건다.
    • end-user : {} 와 같은 식이면 그냥 해당 헤더만 있으면 매칭된다.
    • 위의 4개의 필드도 실상 헤더이나 많이 쓰는 관계로 따로 분리되었고, 그래서 여기에 해당 헤더를 써도 그 값은 무시된다.
• 다운스트림 관련
  • gateways - 게이트웨이를 기반으로 매칭할 수도 있다!
  • sourceLabels - 다운스트림 워크로드의 라벨 기반으로 매칭한다.
  • sourceNamespace - 다운스트림 워크로드의 네임스페이스 기반 매칭
• 기타
  • port
  • queryParams

실습 진행

이번에는 실습 내용이 많아서 이에 최대한 충실하고자 기본 예제를 사용했다.
두 가지 버전을 가진 워크로드가 있을 때, 무작위로 트래픽을 분배하지 않고 원하는 대로 트래픽이 가도록 설정해본다.

기본 환경 세팅은 명시적으로 바꾸지 않는 이상 동일하니, 1W - 서비스 메시와 이스티오 참고.

k create ns istioinaction
k label ns istioinaction istio-injecton=enabled
k ns istioinaction

이번엔 일찌감치 실습에 사용할 파일들을 현 디렉토리에 위치시켰다.

초반 실습들은 이전 실습과 많이 겹쳐서 사실 간단하다.
대신 이번에는 각 리소스 설정이 실제로 어떤 엔보이에 영향을 미치고, 어떤 식으로 설정이 들어가는지 조금 집중적으로 보도록 한다.

기본적인 트래픽 라우팅

kubectl apply -f services/catalog/kubernetes/catalog.yaml
kubectl apply -f ch5/catalog-gateway.yaml
kubectl apply -f ch5/catalog-vs.yaml

기본적인 워크로드와 이에 대응하는 이스티오 리소스를 만든다.

while true; do curl -s http://catalog.istioinaction.io:30000/items/ -I --resolve "catalog.istioinaction.io:30000:127.0.0.1" | head -n 1 ; date "+%Y-%m-%d %H:%M:%S" ; sleep 0.5; echo; done

이번에도 키알리로 트래픽을 확인할 것이므로, 반복 접근을 해둔다.

kubectl apply -f services/catalog/kubernetes/catalog-deployment-v2.yaml

2 버전까지 바로 배포를 진행한다.

하나의 카탈로그 클러스터 안에 두 엔드포인트가 생긴 것이 보인다.

istioctl proxy-config endpoint deploy/istio-ingressgateway.istio-system --cluster 'outbound|80||catalog.istioinaction.svc.cluster.local' -oyaml

추가 인자를 넣어서 조금 더 엔보이의 설정을 면밀하게 관찰할 수 있다.

특정 버전으로만 트래픽 가도록 만들기

현재는 1,2버전이 같이 있는 상태인데 이 둘을 별 달리 구분짓고 있지 않다.
그래서 키알리로 확인하더라도 트래픽이 50퍼씩 동일하게 분산되고 있다.

버전 별로 클러스터를 세부 지정하기 하기 위해 버전 라벨을 사용할 수 있겠다!
참고로 버전 라벨이 보통 많이 쓰여서 키알리에서도 이를 기반으로 시각화를 해주기에 사용할 뿐, 원한다면 얼마든지 다른 라벨을 이용해도 된다.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: catalog
spec:
  host: catalog.istioinaction.svc.cluster.local
  subsets:
  - name: version-v1
    labels:
      version: v1
  - name: version-v2
    labels:
      version: v2

데스티네이션 룰로 부분집합을 정의해보자.
다음에 조금 더 자세히 소개할 데스티네이션 룰은 서비스 레지스트리에 등록된 클러스터를 조금 더 세부적으로 정의하고 설정할 수 있게 해주는 리소스이다.
서비스 레지스트리에 등록된 클러스터에 대한 설정을 하는 것이기 때문에, CDS, EDS에만 영향을 끼칠 것을 짐작할 수 있다.

이를 적용하고 이스티오 컨트롤 플레인의 로그를 살펴보면, 데스티네이션 룰이 만들어졌다고 한 뒤에 여러 XDS 설정이 일어나는 것을 확인할 수 있다.

ads	XDS: Pushing Services:14 ConnectedEndpoints:3 Version:2025-04-21T13:54:52Z/25
delta	CDS: PUSH for node:catalog-v2-57b4fcdc75-p6zt8.istioinaction resources:7 removed:0 size:4.9kB cached:0/3
delta	CDS: PUSH for node:catalog-5899bbc954-bqvvf.istioinaction resources:7 removed:0 size:4.9kB cached:3/3
delta	CDS: PUSH for node:istio-ingressgateway-6567675ffd-jn2nr.istio-system resources:4 removed:0 size:3.9kB cached:0/3
delta	EDS: PUSH for node:catalog-v2-57b4fcdc75-p6zt8.istioinaction resources:24 removed:0 size:4.4kB empty:0 cached:23/24
delta	EDS: PUSH for node:istio-ingressgateway-6567675ffd-jn2nr.istio-system resources:1 removed:0 size:377B empty:0 cached:0/1
delta	EDS: PUSH for node:catalog-5899bbc954-bqvvf.istioinaction resources:24 removed:0 size:4.4kB empty:0 cached:24/24
delta	LDS: PUSH for node:istio-ingressgateway-6567675ffd-jn2nr.istio-system resources:1 removed:0 size:1.3kB
delta	RDS: PUSH for node:istio-ingressgateway-6567675ffd-jn2nr.istio-system resources:1 removed:0 size:539B cached:0/0
delta	LDS: PUSH for node:catalog-5899bbc954-bqvvf.istioinaction resources:23 removed:0 size:37.9kB
delta	LDS: PUSH for node:catalog-v2-57b4fcdc75-p6zt8.istioinaction resources:23 removed:0 size:37.9kB
delta	RDS: PUSH for node:catalog-5899bbc954-bqvvf.istioinaction resources:15 removed:0 size:11.2kB cached:14/15
delta	RDS: PUSH for node:catalog-v2-57b4fcdc75-p6zt8.istioinaction resources:15 removed:0 size:11.2kB cached:14/15
delta	EDS: PUSH request for node:catalog-5899bbc954-bqvvf.istioinaction resources:2 removed:0 size:460B empty:0 cached:0/2 filtered:24
delta	EDS: PUSH request for node:catalog-v2-57b4fcdc75-p6zt8.istioinaction resources:2 removed:0 size:460B empty:0 cached:2/2 filtered:24
delta	EDS: PUSH request for node:istio-ingressgateway-6567675ffd-jn2nr.istio-system resources:2 removed:0 size:460B empty:0 cached:0/2 filtered:1

그런데 로그로만 보면 LDS, RDS 등 너나 할 거 없이 신나게 설정이 적용된 모습을 볼 수 있다.
각각 실제로 설정이 들어갔을까?

istioctl pc cluster catalog-5899bbc954-bqvvf --fqdn catalog.istioinaction.svc.cluster.local

일단 어떤 놈이든 붙잡고 클러스터 설정을 뜯어보면 이렇게 같은 클러스터가 3개가 생긴 게 보인다.
정확하게는 같은 fqdn이 3개인 거고, 기본 클러스터만 있던 상태에서 하위 부분집합 클러스터 2개가 추가로 더 생긴 것이다.

위 그림은 istioctl pc cluster 명령을 json으로 출력한 다음 fx라는 명령 툴을 이용해 적당히 필요 없는 부분은 안 보이게 하고 찍은 것이다.
클러스터를 세부적으로 들여다보면 EDS 타입에 이름에 부분집합 정보가 담긴 클러스터가 들어간 것이 보인다.
메타데이터로도 부분집합 내용이 담겨있다.

istioctl pc endpoint catalog-v2-57b4fcdc75-p6zt8 --cluster "outbound|80||catalog.istioinaction.svc.cluster.local" 

이번엔 엔드포인트 설정으로도 보자.
엔드포인트로 보면 이렇게는 잘 드러나지 않는 것처럼 보인다.

그러나 사실 서브셋 정보를 토대로 각각의 엔드포인트가 생기긴 한 것을 볼 수 있다.
이렇게 여러 개의 엔드포인트가 생긴 이유는 사실 간단하다.
데스티네이션룰로 부분집합을 나눴다고 해서 무조건 각 부분집합으로만 트래픽을 보내야 하는 건 아니다.
당연히 부분집합으로 나뉘었던 기존 클러스터를 대상으로 트래픽을 보낼 수 있어야 하고, 이에 대한 엔드포인트가 그대로 남아있는 것이다.
위에 클러스터 설정을 봤을 때 부분집합에 속하지 않는 클러스터가 있는 것 역시 같은 맥락이다.

게이트웨이쪽 LDS가 건드려지길래 이런 식으로 before after 덤프를 떠서 diff로 차이를 비교해봤는데 서로 달라진 건 없었다.
데스티네이션 룰 리소스의 용도 상 LDS에 영향이 없는 것이 당연하다고 생각했는데, gpt에 물어봤을 때는 ADS가 일어나면서 다른 설정들도 동기화하기 위해 같이 설정이 되는 경우가 많다고 한다.
그러나 실질적으로 변하는 값은 없는 경우가 많다고.

동기화 상태를 보면, 데룰 하나 만들었다고 그냥 모든 XDS가 동기화되는 것을 볼 수 있다..

다른 서비스를 확인해봐도 LDS, RDS 쪽 변화가 없는 것은 마찬가지이다.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: catalog-vs-from-gw
spec:
  hosts:
  - "catalog.istioinaction.io"
  gateways:
  - catalog-gateway
  http:
  - route:
    - destination:
        host: catalog
        subset: version-v1

아무튼 데스티네이션룰로 클러스터에 대한 상세 지정을 했기에 특정 부분집합으로 트래픽이 향하도록 설정하는 것이 가능하다.

버츄얼 서비스는 라우팅 설정을 하는 리소스이기에 실질적인 설정은 RDS에만 이뤄지는 것이 정상이다.

gateways 필드에는 인그레스 게이트웨이만 설정을 받도록 명시했다.
그래서 대상이 된 게이트웨이 엔보이에만 설정이 이뤄진 것을 볼 수 있다.

istioctl pc route -n istio-system istio-ingressgateway-6567675ffd-jn2nr --name http.8080 -ojson

http 관련 설정만 걸었으니 RDS만 설정이 이뤄졌다.
설정에서 대상이 되는 클러스터가 v1을 명확하게 가리키도록 설정된 것을 볼 수 있다.

Dark Launch

다크 런치(dark launch)란 새로운 릴리스로 실제로 트래픽을 보낼 수 있는 상태이지만, 특정 조건을 만족해야만 보낼 수 있도록 하는 전략을 말한다.
간단하게 특정 http 헤더를 추가했을 때만 v2로 가보도록 해보자.

apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: catalog-vs-from-gw
spec:
  hosts:
  - "catalog.istioinaction.io"
  gateways:
  - catalog-gateway
  http:
  - match:
    - headers:
        x-istio-cohort:
          exact: "internal"
    route:
    - destination:
        host: catalog
        subset: version-v2
  - route:
    - destination:
        host: catalog
        subset: version-v1

버츄얼 서비스에서 라우팅 설정을 해준다.

curl http://catalog.istioinaction.io:30000/items -H "x-istio-cohort: internal" --resolve "catalog.istioinaction.io:30000:127.0.0.1" 

이렇게 이미지url 정보가 추가적으로 들어온다면 제대로 라우팅된 것이다!

이건 반복문은 돌리지 않고 연타를 쳤는데 1.1퍼까지는 찍었다 ㅋㅎㅋ..

istioctl pc route -n istio-system istio-ingressgateway-6567675ffd-jn2nr --name http.8080 -ojson 

라우팅 설정이 된 엔보이 설정을 보면 위처럼 설정이 그대로 들어간 것을 볼 수 있다.

메시 내부 라우팅 규칙 설정

지금까지 버츄얼 서비스로 게이트웨이쪽 엔보이에 설정이 되는 것을 확인할 수 있었다.
그러나 이건 어디까지 대상을 게이트웨이로 설정했기 때문이고, 서비스 메시 내부에서 라우팅 적용을 받도록 설정하는 것도 가능하다.
gateways 필드를 기입하지 않으면 이게 기본값이기도 하다.

kubectl delete gateway,virtualservice,destinationrule --all -n istioinaction
kubectl apply -n istioinaction -f services/webapp/kubernetes/webapp.yaml

기존 실습하던 이스티로 리소스만 지우고 새로 배포한다.
또한 웹앱 양식 파일도 같이 배포해준다.
이번에는 catalog 서비스에 게이트웨이에서 바로 접근하지 않고 webapp이 catalog를 호출하도록 세팅할 것이다.

apiVersion: networking.istio.io/v1alpha3
kind: Gateway
metadata:
  name: coolstore-gateway
spec:
  selector:
    istio: ingressgateway
  servers:
  - port:
      number: 80
      name: http
      protocol: HTTP
    hosts:
    - "webapp.istioinaction.io"
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: webapp-virtualservice
spec:
  hosts:
  - "webapp.istioinaction.io"
  gateways:
  - coolstore-gateway
  http:
  - route:
    - destination:
        host: webapp
        port:
          number: 80

이번에는 catalog 앞단에 webapp을 두어서 트래픽을 접근하는 식으로 세팅해보자.

WEBAPP="webapp.istioinaction.io"
while true; do curl -s "http://$WEBAPP:30000/api/catalog" -I --resolve "$WEBAPP:30000:127.0.0.1" | head -n 1 ; date "+%Y-%m-%d %H:%M:%S" ; sleep 1; echo; done
while true; do curl -s -H "x-istio-cohort: internal" "http://$WEBAPP:30000/api/catalog" -I --resolve "$WEBAPP:30000:127.0.0.1" | head -n 1 ; date "+%Y-%m-%d %H:%M:%S" ; sleep 1; echo; done

이번에도 반복 접근을 걸어둔다.

트래픽은 정상적으로 나온다.
그러나 위에서 설정한 버츄얼 서비스는 게이트웨이에서 webapp으로 향하는 값만 설정했다.
그렇다면 webapp에서 catalog로 트래픽은 지금 어떻게 가고 있는 것인가?

apiVersion: telemetry.istio.io/v1alpha1
kind: Telemetry
metadata:
  name: webapp
  namespace: istioinaction
spec:
  selector:
    matchLabels:
      app: webapp
  accessLogging:
  - providers:
    - name: envoy
    disabled: false

이건 간단하게 로깅 세팅을 하면 바로 알 수 있다.
1주차에서 잠시 언급했던 텔레메트리 리소스를 세팅한다.

"HEAD /api/catalog HTTP/1.1" 200 - via_upstream - "-" 0 0 4 3 "172.18.0.1" "curl/8.5.0" "9c8d4bfb-52d2-4db7-a6ac-d5ab8ce0db10" "webapp.istioinaction.io:30000" "10.10.0.25:8080" inbound|8080|| 127.0.0.6:56465 10.10.0.25:8080 172.18.0.1:0 outbound_.80_._.webapp.istioinaction.svc.cluster.local default
"GET /items HTTP/1.1" 200 - via_upstream - "-" 0 698 2 1 "172.18.0.1" "beegoServer" "6dcff67b-1e5b-4b22-a6a2-ae90d2904edc" "catalog.istioinaction:80" "10.10.0.24:3000" outbound|80||catalog.istioinaction.svc.cluster.local 10.10.0.25:48792 10.200.1.98:80 172.18.0.1:0 - default

그럼 webapp 프록시의 로그를 뜯어볼 수 있게 된다.
HEAD는 내 로컬에서 webapp으로 날린 요청, GET이 webapp에서 catalog로 날아가는 요청인데, 여기에서 중요하게 볼 지점은 가장 마지막 부분이다.

webapp의 엔보이는 10.200 대역으로 요청을 날리는데, 이 대역은 현재 쿠버네티스 서비스 대역이다.
즉, webapp에서 catalog로의 요청은 서비스 메시로 처리되지 않고 메시 외부로서 쿠버네티스 서비스로 요청이 날아간 것이다!

RDS 설정을 봐도 약간 확인할 수 있는데, catalog로 가는 라우팅 정보가 들어있기는 하지만 뒤에 버츄얼 서비스는 설정되지 않은 것을 볼 수 있다.

apiVersion: networking.istio.io/v1alpha3
kind: DestinationRule
metadata:
  name: catalog
spec:
  host: catalog.istioinaction.svc.cluster.local
  subsets:
  - name: version-v1
    labels:
      version: v1
  - name: version-v2
    labels:
      version: v2
---
apiVersion: networking.istio.io/v1alpha3
kind: VirtualService
metadata:
  name: catalog
spec:
  hosts:
  - catalog
  gateways:
    - mesh
  http:
  - match:
    - headers:
        x-istio-cohort:
          exact: "internal"
    route:
    - destination:
        host: catalog
        subset: version-v2
  - route:
    - destination:
        host: catalog
        subset: version-v1

그럼 이제 서비스 메시 내부적으로 모든 트래픽을 처리할 수 있도록 라우팅 설정을 해주도록 하자.
아까와 같이 데룰을 만들어 클러스터를 부분집합으로 나눈 뒤에 이를 기반으로 라우팅을 설정했다.
이 설정에서 gateways 필드에 mesh를 세팅했는데, 이렇게 하면 메시 안의 모든 서비스가 진입점이 된다는 뜻이다.
(위에서 말했듯 생략하면 이게 기본 값이다.)

키알리에서도 catalog 쪽을 보면 버츄얼 서비스 아이콘이 생성된 것을 확인할 수 있다.

보다시피 서비스 메시의 모든 서비스의 RDS에 영향을 준 것을 볼 수 있다.
(CDS는 틈만 나면 같이 동기화된다..)

라우팅 설정 정보를 보면 이번에는 명확하게 버츄얼 서비스가 세팅된 것도 확인할 수 있다!

결론

이번 주차의 첫번째는 여태 했던 주차들과 크게 다르지 않다.
따지자면 이스티오 기능들 중 발가락만 핥고 있는 격인데, 기왕 핥을 거 조금 더 성실하게 핥아서 실제 엔보이에 설정이 어떻게 들어가는지도 알아보았다.
재차 강조하지만 엔보이를 잘 알면 알수록 이스티오의 동작 방식을 더 잘 이해할 수 있게 되니, 엔보이에 익숙해지기 위한 시간을 가진다고 생각하고 실습과 공부를 진행하는 게 좋다.

이전 글, 다음 글

• 2W - 인그레스 게이트웨이 실습: 6
• 3W - 트래픽 가중치 - flagger와 argo rollout을 이용한 점진적 배포: 8

다른 글 보기

관련 문서

참고